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Sir: 



APPEAL BRIEF 

Applicant respectfully appeals from the final rejection mailed July 24, 2000. 

I. REAL PARTY IN INTEREST 
The real party in interest is the assignee Intel Corporation. 

II. RELATED APPEALS AND INTERFERENCES 

None. 

III. STATUS OF THE CLAIMS 

All claims are rejected. 

IV. STATUS OF AMENDMENTS 
The amendment after final was not entered. All other amendment were entered. 
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V. SUMMARY OF THE INVENTION 

Referring to Figure 1, a video distribution system 10 may be implemented in a variety of 
different video distribution environments including cable, television broadcast, or satellite as 
examples. The video provider 14, which may be a cable provider or a satellite system provider 
as examples, transmits video, as indicated at 16, to a plurality of receivers 12 which may be 
processor based television receivers. The processor based television receivers may, for example, 
be so called set-top computer systems which use a television receiver as a display. 

Instead of transmitting the video at a set or predetermined time corresponding to the time 
the video will be viewed, the video may be continually or semi-continuously streamed to all of 
the receivers in an encrypted form. Alternatively the video may simply be transmitted in 
advance and stored on a plurality of receivers. The individual receivers 12 may not be capable 
(without additional information) of displaying the transmitted video information. Thus, to the 
extent possible given the bandwidth of the system, video may be transmitted to the receiver 12 
and stored thereon, for example in a memory 22, for viewing at a later time. 

When a user desires to view particular video information, such as a movie, at any time, 
the user may simply request the decryption information, for example, from the video provider 
14. In a two-way transmission scheme the request for decryption information may be 
transmitted over the same transport that conveyed the video. Alternatively, a separate medium or 
channel may be used. In addition, the decryption information may be requested from a source 
different from the video provider 14, in one embodiment of the invention. See specification page 
3, line 2 through page 4, line 10. 

The decryption information may then be transmitted with unrelated video information 16, 
in one example, to the receiver 12. For example, under control by the controller 15, the 
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decryption information may be provided together with information about the intended recipient. 
Equipped with the decryption key for a particular video such as a movie, the receiver 12 can 
decrypt the video and allow the viewer to view the video on demand. 

Where each of the receivers 12 includes a unique identifier and the decryption 
information is coded for the requesting receiver, only the receiver whose identifier matches an 
identifier transmitted with the decryption key is able to decode the decryption key for the 
requested video. In addition, when the receiver requests the decryption information, the receiver 
may not only be provided the decryption information, but appropriate billing provisions may be 
implemented as well. 

Requests for the decryption information may be provided through a telephone network 20 
as one example. As another example, the request may be made over an electronic network, such 
as the Internet using electronic mail. Thus, in effect a back channel may be used to request the 
decryption information from the video provider or other source in one embodiment. The video 
provider (or other source) then may provide not only the decryption information, but in one 
embodiment of the invention, the information needed to access the receiver's memory for the 
selected video information may also be provided. See specification page 4, line 1 1 through page 
5, line 13. 

Referring now to Figure 2, software, in accordance with one embodiment, may be stored 
on the receiver 12 for implementing a video on demand system. The software 26 may begin by 
receiving and storing the encrypted video as indicated in block 28. In one embodiment, this may 
be done at particular times when volume in the transmission channel is low or the transmission 
may be done continuously or semi-continuously so as to store a library of video files on the 
receiver 12. 
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Upon request for video, as indicated in diamond 30 3 the receiver 12 requests a decryption 
key as indicated in block 32. This request may be carried over a back channel, in one 
embodiment of the invention, through a network 20 such as the Internet or a telephone network. 
Next, the video, stored in an encrypted form on the receiver 12, is retrieved as indicated in block 
34. The video may then be automatically decrypted as indicated in block 36, and the display of 
the video may begin as indicated in block 38. 

Generally, it may be desirable to transmit a decryption key for sections or portions of a 
given video. Thus, to view the entire video, the receiver must receive one or more video 
decryption keys, each of which may be used to decrypt a portion (less than all) of the video 
information. The advantage of this technique is that a pirate must obtain a number of video 
decryption keys in order to decrypt the entire video. This makes it harder to pirate the decryption 
keys, decreasing the likelihood of theft of services. For example, a new decryption key may be 
needed for each minute of video. Therefore, it may be desirable to transmit a new decryption 
key every minute, once an initial request for decryption information has been made. See 
specification page 5, line 15 through page 7, line 10. 

If the user wishes to pause the ongoing video transmission (diamond 40), a signal may be 
sent, for example, over a back channel to the video provider 14 requesting a pause authorization 
(block 42). The video provider may respond by providing an acknowledgement number (block 
44). When the user wishes to resume the video transmission, the user may simply press a 
"resume" key and provide the acknowledgement number. The video provider then knows when 
the particular receiver paused and provides the appropriate keys to allow the user to continue to 
view the rest of the video that was already requested, and presumably, billed. 
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Turning now to Figure 3, an example of a system that may be used as a receiver 12 is 
illustrated. The receiver 12 may include a processor 65 coupled to an accelerated graphics port 
(AGP) chipset 66. The chipset 66 may be coupled to system memory 68 and the accelerated 
graphics port bus 70. The bus 70 in turn may be coupled to a graphics accelerator 72, also 
coupled to a video or television receiver 73. 

The chipset 66 may also be coupled to a bus 74 that receives a TV tuner/capture card 76. 
The card 76 may be coupled to a television antenna 78 which may also be a satellite antenna or a 
cable connection as additional examples. A connection to a network 90, such as a modem 
connection to the Internet or a network controller connection to a computer network may also be 
provided. 

The bus 74 is coupled to a bridge 80 which in turn is coupled to a hard disk drive 82. The 
hard disk drive 82 may store the software 26 and 46. The software 100 may be script transmitted 
from the transmitter 14 to assist in locating stored video information. See specification page 7, 
line 1 1 through page 8, line 4. 

Claim 1 inter alia calls for a controller to receive a request to pause the play of video and 
to automatically request a code to enable video play to be resumed at a later time. 

Claim 4 calls for a controller that receives a request for a code to enable the play of video 
to be paused and to be resumed at a later time and in response said controller automatically 
provides said code. 

Claim 21, dependent on claim 4, calls for a controller that transmits an acknowledgement 
number to a receiver in response to a request for a code to enable the play of video to be paused 
and to be resumed at a later time. 
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Claim 10 calls for automatically requesting a code to enable video to be played at a later 

time. 

Claim 22 dependent on claim 10, calls for receiving an acknowledgement number and 
using the acknowledgement number to resume the play of video. 

Claim 14 calls for automatically requesting a code to enable the play to be resumed at a 
later time in response to a request to pause the play of video. 

Claim 24, dependent on claim 14, calls for enabling the user to press a button to resume 
the play of the video and in response to the operation of the button, automatically transmitting 
the code to enable resumed play of the video. 

The variety of different claimed elements in the above-recited claims demonstrates that 
there are a number of different ways to enable the play of video to be paused and restarted, for 
example without additional charge. 

VI. ISSUES 

A. Can a Claim be Rejected as Obvious When a Claimed Element is Nowhere 
Suggested in the Prior Art? 

In the final rejection and the advisory action, the Examiner concedes that with respect to 
each of the claims set forth above, elements are nowhere taught in the sole cited reference. 
Instead, the Examiner appears to believe that an obviousness per se argument should apply. The 
applicant contends that no such argument is applicable and that it is Examiner's burden to 
substantiate an inherency rejection and that in this case an inherency rejection has not and can 
not be made out. 

VII. GROUPING OF THE CLAIMS 
For brevity on appeal, claims 1, 2 and 3 may be grouped, claims 4-9 may be grouped, 
claims 10-13, 17-20 and 23 may be grouped and claims 14, 15, 25 and 26 may be grouped. 




VIII. ARGUMENT 

A. Can a Claim be Rejected as Obvious When a Claimed Element is Nowhere 
Suggested in the Prior Art? 

Claim I was rejected under § 103 based on the patent to Russo, That claim inter alia 
calls for a controller to receive "a request to pause the play of said video and automatically 
request a code to enable video play to be resumed at a later time". 

The total disclosure relating any type of pause feature set forth in the Russo patent is as 
follows: 

In the event that the individual cannot finish a particular program 
once selected for enjoyment, in a further alternative embodiment, 
the system will keep track of exactly where the operator left off 
and pick up at that point without an additional charge, thus 
ensuring that an operator is not charged twice for selecting the 
same program more than once. 

See column 11, lines 14-20. 

Thus, all that Russo teaches is the functional idea of being able to suspend the playback 
and resuming without charge. Russo does not say a thing about how to do it. 

Nonetheless, the Examiner states that: 

It would therefore have been obvious to consider such a feature as 
a pause function whereby the controller 150 would recognize this 
command by an inherent code, as a separate command from a 
resume or play command, thereby meeting claims 1 and 14. 

In effect, the Examiner's statement amounts to nothing more than an admission that 
Russo does not teach the elements of claim 1 but that they would be obvious in the absence of 
any supporting teaching from the prior art. 

To argue that undisclosed features are inherent, no other permissible operation of the 
prior art embodiment must be possible other than that claimed. In other words, for the reference 
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to inherently teach the feature, it is not sufficient that it "permissibly" may operate in the claimed 
fashion, it must necessarily so operate. See M.P.E.P. § 21 12 at pp. 2100-40. 

Here, claim 1 calls for a controller to "automatically request a code to enable video play 
to be resumed at a later time". There is absolutely nothing in the sole cited reference, the Russo 
patent, that in any way suggests automatically requesting a code to enable video play to be 
resumed. 

The claimed feature can not be inherent because there are a large number of ways to 
implement a pause feature, many of which do not involve automatically causing a controller to 
automatically request a code. The Examiner is required to provide "a basis in fact and/or 
technical reasoning to reasonably support the determination that the allegedly inherent 
characteristics necessarily flows from the teaching of the prior art." Id. (Emphasis in original). 
Ex parte Levy, 17 U.S.P.Q.2d 1461, 1464 (Bd. Pat. App. & Interf. 1990). 

We are left with a rejection with absolutely no prior art support for at least one missing 
element. Therefore, the rejection should be reversed. 

Claim 4 calls for a controller that receives a request for a code to enable the play of video 
to be paused and to be resumed at a later time and in response the controller automatically 
provides the code. No such feature is anywhere taught in the sole cited reference. Again, there 
is no reason why the reference necessarily would receive a request for a code and in response 
provide a code and moreover there is no reason that the code would be provided automatically as 
a matter of absolute necessity. 

Claim 21 includes the limitation that the controller automatically transmits an 
acknowledgement number to a receiver in response to a request for a code to enable the play of 
video to be paused and to be resumed at a later time. Thus, claim 21 covers the situation where 
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the transmission system includes a controller that transmits decryption information to receivers, 
and receivers request a code to enable play of video to be paused, and the transmitter 
automatically provides such a code. Again, no such feature is taught by Russo which merely 
mentions the idea of a pause feature but provides no information about how to implement one. 

In the said vein, claim 10 calls for automatically requesting a code to enable the video to 
be played at a later time. The cited reference has no teaching of requesting a code or for that 
matter automatically requesting a code. There is no reason why such a feature need be 
inherently present in the cited reference. For example, the cited reference could require that the 
user specifically request such a code. 

Similarly, claim 22 calls for "receiving an acknowledgement number and using said 
acknowledgement number to resume the play of video". This claim covers the receiving end of a 
method in which an acknowledgement code is requested to enable pause and the 
acknowledgement code is provided from a remote source. All that Russo teaches is keeping 
track of where the user stopped watching the program. It does not say how the user is able to 
resume. For example, the user may be required to call up the service provider and request 
permission to resume. 

In response to a request to pause the play of video, claim 14 calls for automatically 
requesting a code to enable the play to be resumed at a later time. No such specific disclosure is 
contained within the cited reference. Again, there is no reason to believe that inherently the 
reference must request a code or that the reference must automatically request a code and no 
such suggestion is provided. As before, it is more reasonable to believe that there are many 
different ways to implement the pause feature and therefore the inherency rejection is completely 
unfounded. 
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Claim 24 calls for enabling the user to press button to resume the play of the video and in 
response to operation of the button, automatically transmit a code to enable the resume play of 
said video. Again, there is no teaching of any kind of button or button operation in Russo. 
Moreover, there is no teaching of any type of feature which automatically transmits the code to 
enable resumed play of video. 

IX. CONCLUSION 
Since the rejections of the claims are baseless, they should be reversed. 

Respectfully submitted, 



Date: 




TROP, PRUNER & HU, P.C. 
8554 Katy Freeway, Suite 100 
Houston, TX 77024 
713/468-8880 [Ph] 
713/468-8883 [Fax] 
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APPENDIX OF CLAIMS 

The claims on appeal are: 

1 . A receiver for receiving video information from a video transmitter comprising; 
a storage medium for storing video information received by a receiver; 

a decryption engine to decrypt stored video information; and 
a controller to control the storage medium and the decryption engine and request 
decryption information for the engine, said controller to control the play of video, to receive a 
request to pause the play of said video and to automatically request a code to enable video play 
to be resumed at a later time. 

2. The receiver of claim 1 wherein said controller includes a processor. 

3. The receiver of claim 1 wherein said engine is adopted to decrypt stored video 
upon receipt of a request to view stored video. 

4. A video transmission system comprising: 

a video transmitter that transmits video to a plurality of receivers for display at a 

later time; and 

a controller that transmits decryption information to said receivers to enable video 
upon request, said controller receives a request for a code to enable the play of video to be 
paused and to be resumed at a later time, and in response said controller automatically provides 
said code. 



5. The system of claim 4 wherein said controller also is adapted to transmit an 
identifier which identifies a particular receiver to receive said decryption information. 

6. The system of claim 5 wherein said controller is part of said transmitter. 

7. The system of claim 4 wherein said video transmitter transmits video over a cable 

system. 

8. The system of claim 4 wherein said video transmitter transmits video over a 
satellite system. 

9. The system of claim 4 wherein said transmitter also transmits information to assist 
in locating particular video files transmitted by said transmitter to said receivers. 

10. A method comprising: 

storing encrypted video in a receiver; 
requesting a decryption key for said stored video; 
playing said video; 

receiving a request to pause said play of video; and 

automatically requesting a code to enable said video to be played at a later time. 

1 1. The method of claim 10 including receiving the encrypted video from one source 
and receiving the decryption key from a second source. 
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12. The method of claim 10 including receiving the video and said decryption key 
from the same source. 

13. The method of claim 10 including receiving an identifier to identify a particular 
receiver to receive said key. 

14. A video distribution method comprising: 
storing video for selection by the recipient; 

upon request by the recipient, allowing the recipient to select for viewing a stored 

video; 

playing said video; and 

in response to a request to pause the play of said video, automatically requesting a 
code to enable play to be resumed at a later time. 

15. The method of claim 14 including providing a graphical user interface which 
displays the video information which is available for selection by the user. 

16. An article comprising a medium for storing instructions that cause a processor 
based system to: 

store video for selection by the recipient; 

upon request by a recipient, allow the recipient to select, for viewing, video 
previously stored; 
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play said video; and 

in response to a request to pause the play of said video, automatically request a 
code to enable play to be resumed at a later time. 

17. An article comprising a medium for storing instructions that cause a processor 
based system to: 

store encrypted video to a receiver; 

request a decryption key, for said stored video; 

play said video; 

receive a request to pause said play of video; and 

automatically request a code to enable said video to be played at a later time. 

18. The article of claim 17 including instructions that cause a processor based system 
to receive the encrypted video from one source and receive the decryption key from a second 
source. 

19. The article of claim 17 including instructions that cause a processor based system 
to receive the video and said decryption key from the same source. 

20. The article of claim 17 including instructions that cause a processor based system 
to receive an identifier to identify a particular receiver to receive said key. 
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. . # 4 

21. The system of claim 4 wherein said controller transmits an acknowledgement 
number to a receiver in response to a request for a code to enable the play of video to be paused 
and to be resumed at a later time. 

22. The method of claim 10 further including receiving an acknowledgement number 
and using said acknowledgement number to resume the play of video. 

23. The method of claim 22 wherein using said acknowledgement number includes 
using said acknowledgement number to resume the play of video without an additional charge. 

24. The method of claim 14 further including enabling the user to press a button to 
resume the play of said video and in response to the operation of said button, automatically 
transmitting the code to enable resumed play of said video. 

25. The method of claim 24 further including receiving a key to enable decryption of 
the video. 

26. The method of claim 25 including resuming the play of video from the point 
where the video play was paused. 
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